Sams Teach Yourself MCSE Windows NT Server 4 in 14 Days
(Publisher: Macmillan Computer Publishing)
Author(s): David Schaer, et al
ISBN: 0672311283
Publication Date: 12/15/97

2.6.2. The Role of the PDC

Grouping systems into a domain makes controlling logon security easier. This is vastly different from a workgroup that does not have centralized security.

The primary domain controller (PDC) is like the head bouncer at a club. As users log on to the domain, it is the responsibility of the domain controllers to validate the users’ credentials by comparing the user names and passwords provided against the SAM database. Each domain has only one PDC; it is the first computer installed within a domain.

Several hardware factors govern the number of users a PDC can support. Microsoft’s official guidelines are shown in Table 2.3.

During the installation of the PDC the security ID (SID) for the domain is created. The SID is a unique identifier, similar in concept to your social security number. You can change your name, but your social security number remains the same. This is how it works with a domain: Although you can rename a domain, as shown in Figure 2.8, the SID associated with it does not change.

Figure 2.8.  Renaming the KNOWLEDGE domain to MASTERDOM.

Although renaming a domain is possible, this will require you to enter the new name at each client computer and break and re-established any trusts.

2.6.3. The Role of the BDCs

The job of the BDCs is to validate logon requests. The SAM database held by a BDC is simply a copy of the one maintained by the PDC and is kept synchronized with that of the PDC by the NetLogon service.

The general guideline is that you must have one domain controller for every 2,000 accounts. It is also recommended that you always have at least one BDC, regardless of the number of accounts in your domain. For example, a domain with 10,000 accounts would need 5 domain controllers: one PDC and four BDCs.

These calculations assume that no extra burdens are placed upon your domain controllers. BDCs are commonly used as application, mail, or print servers. This increases the demand on the machines’ resources and increases the number of domain controllers you will need to support your domain.

There is no limit to the number of BDCs you can install within a domain. BDCs are placed strategically throughout the physical network to ensure efficient logon and provide fault tolerance to the NT Directory Services. If the PDC crashes or is brought down for an extended period of time, it is possible to promote a BDC to take over the role of the PDC. If a PDC is not available, it will not be possible to make any changes to the SAM database.

In Figure 2.9, NTBACKUP is being promoted to the role of primary domain controller. NTMASTER, the current PDC, will be automatically demoted to the role of BDC. This is can be done by a member of the Domain Admins group using Server Manager.

Figure 2.9.  NTBACKUP is being promoted to the role of PDC.

When installing a backup domain controller it is important to ensure that the BDC can communicate with the PDC. This means that the systems must have at least one protocol in common. If the BDC cannot contact the PDC during the BDC’s installation, the installation will fail.

At the time of installation, the PDC provides the BDC with the SID unique to that domain. Because the domain SID is assigned to a BDC only during installation, moving a BDC to another domain will require reinstallation.

2.6.4. Stand-Alone and Member Servers

A stand-alone server has all of the features of Windows NT Server available to it. Unlike domain controllers, a stand-alone server does not participate in user account validation or directory replication. Stand-alone servers are useful for providing file/print sharing and applications services because the computer they are on does not also have to provide other services. A stand-alone server can be a member of a domain or just a workgroup. A stand-alone server that participates in a domain is also called a member server.

Neither a stand-alone nor member server can serve as a logon server. Each server maintains an independent security account manager database. The SAM database held at the servers is identical in structure to that of an NT Workstation but different from that of a domain controller. This is one of the reasons why it is possible to upgrade an NT Workstation to become a member server but not a domain controller. Upgrading a stand-alone or member server to become a domain controller is not possible; instead, you must reinstall the system.

Stand-alone and member servers are not interrupted by clients requesting to be validated on the domain. These systems are, therefore, better suited than domain controllers to be application servers.

2.6.5. Placement of Domain Controllers

Proper placement of the domain controllers is central to controlling network traffic and providing adequate response during periods of high activity. The most common method of designing a domain is to do so geographically. That is, a domain might be created for each building in a complex or each city in which the company has offices. Placing the domain controllers that are meant to do the most logon validation activity closest to the most users on your network is often helpful. Placing certain resource servers on subnets in your network to reduce the traffic load on other subnets is also helpful.